My Friend the Customer

The Customer is the only non-developer role in eXtreme Programming (XP). The Customer’s explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. In this paper, we provide a small collection of patterns that that describe useful models for the customer, showing how other roles involved in the process can be adapted to also serve as the XP customer. Introduction The initial description of Extreme Programming (XP) assumed an in-house project with an inhouse customer, so that the goals and attitudes of customers and developers are closely aligned. Many projects are much more remote: often, developers never meet or speak to their actual customers, who may work for a different organisation in a different continent. Even the flagship C3 project failed because they were targeting the wrong customer in the end [2]. The Customer is the only non-developer role in eXtreme Programming . The Customer’s explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing): unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, end users, and defending the project against office politics, while at the same time maintaining the trust of both the development team and the wider business environment. The customer role is critical in making decisions about “what to build” and, in the minimalist philosophy of XP, the following are recommended for the customer role [6]: • The customer is an integral part of the team and should be on-site with the team • The customer writes user stories and then discusses each requirement directly with the programmers • The customer is responsible for all business decisions including prioritising user story development • The small 2-3 week iterations allow the customer to evolve their requirements based on concrete working software • The customer regularly tests the software to confirm it works as expected. XP explicitly assumes that the customer knows the domain well and is able to make decisions and as such does not provide ‘how-to’ advice on gathering, expressing and prioritising requirements. In this paper we present several patterns that all address this general context, that identify several different ways of solving the same problem: how to find customers, especially for out-